중복코드가 항상 나쁜 것도 아니고, 정리되지 않은 코드가 항상 이해하기 어려운 것도 아니다. 때로는 DRY하지 않은 것이 도움이 될 때가 있다. 디자인 패턴, 코드 아키텍쳐, DRY 코딩 모두 결국엔 수단일 뿐이다. 코드를 추상화(abstraction)시키는 것보다 중복(duplicate) 코드가 더 이해하기 쉽고 관리하기 쉽다면 그렇게 하면 된다. 많은 개발자들이 "나쁜 추상화보다 중복 코드가 낫다"에 동의를 하는데, 그 이유는 무엇일까? 다음 이야기를 보자.
어느날 한 개발자가 중복 코드를 발견한다. 그는 중복 코드를 추출해서 적절한 이름을 주었다. 이렇게 새로운 추상화가 탄생했다. 그것은 새 함수일 수도 있고, 새 클래스일 수도 있다. 아 완벽해. 개발자는 행복히 갈길을 갔다.
그렇게 시간이 흘렀다...
새로운 요구사항이 등장한다. 현재 코드는 이 새로운 요구사항을 구현하기에 거의 완벽하다.
다른 개발자가 개발을 맡게 되고, 그는 이 거의 완벽한 추상적 형태를 지켜야한다는 강박에 사로잡힌다. 그러나 이 거의 완벽한 코드는 모든 경우에 맞아 떨어지지 않았다. 그래서 그는 인자를 추가했고, 분기를 추가하게 되었다. 그렇게, 원래 완벽했던 추상적인 코드는 사라지고 경우에 따라 다른 동작을 하는 요물만 남게 되었다.
그렇게 또 시간이 흘렀다...
(대충 반복 된다는 내용)
코드는 이제 더이상 알아볼 수가 없다...
새로운 요구사항이 등장한다...
당신은 개발을 맡게 되고.........
이미 있는 코드는 상당한 영향력을 행사한다. 어느 정도냐면, 자신의 밥벌이를 위해 일부러 레거시를 개선하지 않는 사람도 있다. 사실 이 얘기를 하려는 건 아니고, 사람들은 자신의 주관이 엄청 강하지 않은 이상 이미 있는 코드를 보면 최대한 그 형태를 유지하면서 개발하려고 한다. 남이 시간을 들여 만든 것이니 지켜줘야한다는 생각도 있는 듯하다. 하지만 안타깝게도 그 결과물은 더 복잡하고 더 이해하기 힘든 코드일 뿐이다.
앞의 이야기에서 당신이 개발을 맡게 될 때, 당신은 기존의 코드를 바꾸려 노력하지만 매우 매우 어렵다는 걸 느낀다. 당신이 보고있는 코드는 하나의 추상화를 나타내는게 아닌 분기로 가득찬 모호한 관념 덩어리일 뿐이다. 이해하기는 어렵고, 오류가 발생하기 쉬운 상황, 당신은 어떻게 할 것인가?
우선 기존 코드의 추상화를 지켜야한다는 강박을 버리자. 때로는 뒤돌아가야할 때가 있는 법이다. 먼저 기존 코드가 호출되는 곳 마다 중복 코드를 만들자. 각각 호출되는 곳에서 쓰이는 인자, 분기를 파악한 뒤 알맞게 수정한다. 필요없는 나머지 부분은 제거한다. 이렇게 하면 추상화와 분기 모두 사라지고 호출 단에서 정말 필요한 부분만 남게된다. 이 상태에서 다시 추상화를 시도해 볼 수 있다.
이미 종잡을 수 없어진 코드를 계속 안고 기능을 추가하는 것은 매우 어렵다. 설령 기능 추가에 성공 하더라도 점점 난해한 코드가 될 것이다. 이미 있는 코드를 너무 받들진 말자. 항상 현상황에 맞춰 프로젝트의 코드를 재구성할 필요가 있다는 마음가짐으로 개발하자.
다음 두 글을 번역, 참조, 간접 인용하였다.